home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-appleip-kip-gateway-00.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
80KB
|
2,242 lines
DRAFT Philip Budne
Shiva Corporation
July 1993
KIP AppleTalk/IP Gateway Functionality
$Revision: 1.33 $
July 6, 1993
1. Status of this Memo
This DRAFT documents the functionality of the Stanford ``KIP''
AppleTalk/IP ``Gateway'' (also called the ``SEAGate code'', ``IP-
Ether/AppleTalk Gateway'', or ``Croft Gateway'').
This draft document will be submitted to the RFC editor as an
Informational Document.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress''.
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
This document expires December 31, 1993. Distribution of this memo
is unlimited.
This memo was started as an effort to describe ``IPTalk'' for the
AppleTalk-IP Working Group of the Internet Engineering Task Force
(IETF). It became apparent that since no protocol standard or
DRAFT KIP AppleTalk/IP Gateway July 1993
description existed that implementation specific information was
unavoidable. KIP is the prototypical AppleTalk/IP Gateway
implementation and is available in source form. KIP's functionality
forms the basis for many commercial products available today.
2. History
Following the introduction of the Macintosh computer in 1984, Apple
donated many units to universities where Ethernet and TCP/IP were the
primary networking technologies. The Macintosh had clear advantages
for text processing applications, including an easy to use user
interface, bit-mapped display, and a built-in network adaptor for the
sharing of laser printers. However, it was equally clear that the
absence of connectivity to existing large computing systems was a
serious limitation. Work began at several large universities (notably
Dartmouth, Stanford and CMU) to provide gateways and client software.
The original ``Stanford Ethernet Applebus Gateway'' was created at
Stanford University in 1985 by Bill Croft and was known as the
``SEAGate''. The hardware consisted of off-the-shelf Multibus
components; a ``SUN 1'' 68000 CPU card, an Interlan NI3210 Ethernet
card, and a simple homebrew Zilog 8530 SCC based ``AppleBus''
interface. The SEAGate source code and hardware documents were
freely available to members of the Internet community. The initial
version provided simple transport of encapsulated IP datagrams from
AppleTalk-based Macintosh computers to Ethernet based IP hosts. Later
versions added encapsulation of AppleTalk in IP and full AppleTalk
routing capabilities. The SEAGate was configured by editing include
files compiled into the gateway code, and was downloaded over a
serial port on the CPU card.
The Kinetics FastPath was created using this technology in mid-1985
and consisted of a 10Mhz 68008 with 48K of battery backed SRAM, an
i82586 and a Zilog 8530 SCC. A PROM provided for download over
LocalTalk and a library of buffer management and LocalTalk I/O
routines for use by the downloaded application.
The SEAGate code was ported to the FastPath and continued to evolve,
and was renamed ``KIP'' for the ``Kinetics IP'' Gateway. The name
``KIP'' is used in this document only in reference to the gateway
software. Unless otherwise noted, all descriptions refer to the June
1988 (06/88) release of KIP.
3. Terminology
The KIP ``Gateway'' implements protocols for encapsulation of IP
datagrams [RFC-791] in DDP for transmission over AppleTalk [Sidhu90]
internets (IP in DDP), and encapsulation of DDP datagrams in UDP
Budne Expires December 31, 1993 [Page 2]
DRAFT KIP AppleTalk/IP Gateway July 1993
[RFC-768] for transmission over IP internets (DDP in UDP). Both have
been called ``KIP'' encapsulation; IP in DDP (herein called DDP/IP)
has also been called ``Dartmouth encapsulation'', ``MacIP'' and
``Croft encapsulation'' while DDP in UDP (herein called UDP/DDP) has
been called ``UDPTalk'', ``IPTalk'', ``AppleTalk in IP'', ``AppleTalk
over UDP'', and ``IP tunneling''. KIP can speak both EtherTalk Phase
1 and UDP/DDP on Ethernet. This capability has been called
``doubletalk''.
The primary existing UDP/DDP host implementation of AppleTalk is the
Columbia AppleTalk Package (CAP) for Un*x systems. All references to
CAP are for Columbia Version 5.0 (using abkip.c).
The KIP sources use the historical terms ``AppleBus'' and
``AppleTalk'' in reference to the ``LocalTalk'' physical medium, as
KIP pre-dates the introduction EtherTalk (and thus the use of the
name AppleTalk for the protocol family rather than the medium). The
term ``Kbox'' is used here to refer to a FastPath running KIP (or any
functionally similar hardware and software).
All constants are in decimal unless otherwise noted.
The following ``C'' type definitions apply to all data structures and
code:
typedef unsigned char u_char; /* 8 bit ordinal */
typedef unsigned short u_short; /* 16 bit ordinal */
typedef unsigned long u_long; /* 32 bit ordinal */
typedef long iaddr_t; /* internet address */
4. UDP/DDP encapsulation
This section describes the algorithms and data structures used by KIP
to implement UDP/DDP encapsulation.
4.1. Motivation
UDP/DDP encapsulation was developed before Apple established a
standard method for the transmission of AppleTalk over Ethernet. One
of the primary strengths (and weaknesses) of UDP/DDP is that it uses
static, centrally administered routing information for the UDP/DDP
backbone, eliminating the background chatter generated by RTMP and
ZIP. In addition one gains the ability to use the large
infrastructure of existing IP internets to transport AppleTalk over
long distances.
Budne Expires December 31, 1993 [Page 3]
DRAFT KIP AppleTalk/IP Gateway July 1993
IP networks on which UDP/DDP routers and endnodes are homed are
assigned AppleTalk network numbers. This distinguishes UDP/DDP from
a strict point-to-point ``tunneling'' model in that endnodes can be
implemented and it allows complete interconnectivity between routers
without a quadratic number of links.
Because of the static nature of UDP/DDP routes, partial (non-
transitive) network connectivity can be engineered (ie; A can see B
and C, but B and C cannot see each other).
4.2. UDP/DDP network numbers
KIP and CAP configuration files usually represent AppleTalk network
numbers as a dotted pair of decimal octets, thus network 258 is
represented as 1.2. AppleTalk network numbers for UDP/DDP networks
are chosen manually, and are arbitrary; In fact, KIP does not learn
from ``seed'' routers at all, and all AppleTalk port network numbers
must be manually configured. Each IP network which is to contain
UDP/DDP hosts (ie; CAP clients and servers) must be assigned a
UDP/DDP AppleTalk network number.
A common convention for the representation of 8 bit subnets of a
class B network is to put the subnet number in the low octet and an
arbitrary constant in the top octet. If the subnet is also used for
EtherTalk a different high octet is used.
IP subnet UDP/DDP net EtherTalk net
_________________________________________
129.2.50.0 55.50 57.50
129.2.100.0 55.100 57.100
129.2.200.0 55.200 57.200
As on any Phase 1 network, there can only be 254 hosts on a UDP/DDP
network. Only the first 254 hosts (low octet equal to 1 through 254)
of a network with more than 8 bits of host number are eligible to
participate in UDP/DDP.
IP (sub-)networks with more than 254 hosts can be represented as
several UDP/DDP networks at the cost of redundant NBP lookup
broadcast traffic.
4.3. UDP/DDP Node numbers
Each CAP UDP/DDP host must be associated with one UDP/DDP network
(even if the underlying IP host is multi-homed). The AppleTalk node
number of a UDP/DDP host is always the low order octet of the host's
IP address on the connected UDP/DDP network.
Budne Expires December 31, 1993 [Page 4]
DRAFT KIP AppleTalk/IP Gateway July 1993
4.4. UDP/DDP Address resolution
Since UDP/DDP encapsulation converts AppleTalk addresses to IP
addresses algorithmicly, no additional Address Resolution Protocol is
required.
4.5. UDP/DDP packet format
UDP/DDP packets are encapsulated in UDP with the IP destination
address and UDP source and destination ports calculated based on
route type (see next section).
Each UDP/DDP packet contains a dummy three byte LAP header
(destination, source and type) the same as LocalTalk and EtherTalk
Phase 1. This has the helpful effect of assuring alignment of the
encapsulated data (otherwise the DDP header would cause odd
alignment). UDP/DDP packets output by KIP always have a LAP
destination of 250 and a LAP source of 206 (which spells ``FACE'' in
a hex dump).
Packets originated by CAP have the source and final destination nodes
numbers equal to the DDP source and destination node (regardless of
the destination network)!! KIP and CAP only send packets of LAP type
2 (long DDP).
KIP ignores the LAP header on input, and a long DDP packet must
follow.
4.6. UDP/DDP Routing
The following ``C'' data structure is used by KIP to internally
represent all AppleTalk routes:
struct aroute {
u_long node; /* next hop/IR: AT node OR IP addr */
u_short net; /* atalk net number, 0 if unused */
u_char flags; /* flags */
u_char hops; /* number of hops to this net */
u_char zone; /* zone index + 1 */
u_char age; /* age of entry in 20 second ticks */
u_char port; /* index of port route came in on */
};
Budne Expires December 31, 1993 [Page 5]
DRAFT KIP AppleTalk/IP Gateway July 1993
/* flag fields */
#define arouteTYPE 0xe0 /* up to 8 types */
#define arouteCore 0x10 /* 'node' is a "core" gateway */
#define arouteAA 0x08 /* this entry received via AA */
#define arouteSUBTYPE 0x03 /* TYPE specific information */
/* Kbox Type */
#define arouteKbox 0x80 /* 'node' is IP addr of a Kbox */
# define arouteEtalk 0x01 /* 'net' is for Kbox EtherTalk */
/* Net Type */
#define arouteNet 0x40 /* IP net allows directed cast */
# define arouteBMask 0x03 /* directed bcast format mask */
/* Host Type */
#define arouteHost 0x20 /* IP rebroadcast host */
# define arouteAsync 0x02 /* virtual async atalk net */
Note:
The `arouteTYPE' field should be treated as an
enumeration despite the assignment of separate bits for
the existing values.
Similarly, the `arouteSUBTYPE' bits have not always been
recognized as `arouteTYPE' specific.
Finally, the `arouteCore' flag should be associated only
with ``Kbox'' routes.
The KIP AppleTalk routing table contains three types of routes;
``Direct'', ``Local'', and ``IP''.
4.6.1. Direct
The routes for the directly connected LocalTalk and EtherTalk
networks have zero in their `hops', `node', and `flags' fields. The
first route in KIP's routing table is for the LocalTalk port, and the
third is for the EtherTalk port (if configured).
4.6.2. Local
For routes learned via RTMP on the LocalTalk or EtherTalk interfaces,
`node' is the AppleTalk node number of an AppleTalk router on the
Budne Expires December 31, 1993 [Page 6]
DRAFT KIP AppleTalk/IP Gateway July 1993
connected network, and `port' is the index of the associated
interface. The `flags' field is zero and the `hops' field is non-
zero.
4.6.3. IP
For UDP/DDP routes (destinations that will be reached by sending the
AppleTalk DDP packet encapsulated in UDP), member `node' in the
`aroute' struct is the IP address of another Kbox or an IP network.
The flags field contains information on the type of ``IP'' route.
AppleTalk ``IP'' routes come in four flavors; ``Net'', ``Host'',
``Kbox'', and ``Async''. ``Net'', ``Host'', and ``Async'' routes all
reach clients on (or connected to) IP hosts (which are not capable of
speaking ``native'' AppleTalk), while ``Kbox'' routes represent
native AppleTalk (LocalTalk and EtherTalk) networks reached by
through IP networks.
4.6.3.1. Net
If the `arouteTYPE' bits of the `flags' field are equal to
`arouteNet', the AppleTalk network `net' is a UDP/DDP net coresident
with an IP network that can be reached with directed broadcasts. The
`arouteBMask' bits of the `flags' field of the `aroute' struct are
the number of low order octets (zero to three) of ones (hex `0xff')
to logically OR with the network number in the `node' field to
produce the (directed) broadcast address. The second route in KIP's
routing table is a ``Net'' route to the directly connected
Ethernet/IP network.
4.6.3.2. Host
If the `arouteTYPE' bits of the `flags' field are equal to
`arouteHost', the AppleTalk network `net' is a UDP/DDP net coresident
with an IP network that cannot be reached by directed broadcasts.
The `node' field of the `aroute' struct is the address of a
``rebroadcast host'' which can broadcast packets on the destination
network. KIP 06/88 does not check the ``subtype'' bits (See below
section on ``Async'' routes).
4.6.3.3. Kbox
If the `arouteTYPE' bits of the `flags' field are equal to
`arouteKbox', this AppleTalk network is reached by sending the DDP
datagram encapsulated in UDP to the router located at address `node'.
``Kbox'' routes can refer to either ``local'' routes learned by other
gateways via RTMP and distributed by the ``core'' gateway mechanism,
or routes downloaded from the AppleTalk Administrator (AA) host in
Budne Expires December 31, 1993 [Page 7]
DRAFT KIP AppleTalk/IP Gateway July 1993
the initial route table. The Un*x AA server implementation
distributed with KIP is `atalkad'. The `arouteEtalk' bit in the
`arouteSUBTYPE' field exists as internal information used by
`atalkad' to differentiate LocalTalk and EtherTalk networks for
configuration purposes, and is not used by KIP at all (but is
nonetheless passed to, and saved by KIP).
4.6.3.4. Async
``Async'' is a recent extension which allows datagrams for a virtual
AppleTalk network to be forwarded to a single IP host with the UDP
port demultiplexed by DDP destination node number. This allows the
gateway to deliver DDP datagrams for each possible node on the Async
network to a different Un*x user process with no intermediary.
``Async'' networks are implemented as a subtype of ``Host'' networks,
with `arouteSUBTYPE' set to `arouteAsync'. Implementations which do
not understand ``Async'' routes will treat them as ``Host'' routes,
with undesirable results.
4.7. IP Route Algorithms
In ``Kbox'', ``Net'', and ``Host'' routes the destination UDP port is
demultiplexed based on the destination DDP socket (except for DDP
broadcasts to ``Host'' networks). This allows the gateway to deliver
DDP datagrams for each possible DDP socket to a different Un*x user
process with no intermediary.
The following table shows how the `aroute' type and the DDP
destination node select algorithms to calculate the UDP destination
port and IP destination address.
IP dest addr algorithm / UDP dest port algorithm.
IP Route Type DDP unicast DDP broadcast
___________________________________________
Net Alg A/Alg P Alg B/Alg P
Host Alg A/Alg P Alg C/Alg Q
Kbox Alg C/Alg P Alg C/Alg P
Async Alg C/Alg R Alg C/Alg S
The UDP source port is always calculated by applying Algorithm P to
the ddp source socket.
In the following code fragments the variable `ddp' is of type `struct
DDP' and describes the long DDP header of the outgoing AppleTalk
Budne Expires December 31, 1993 [Page 8]
DRAFT KIP AppleTalk/IP Gateway July 1993
packet;
struct DDP {
...
u_short dstNet; /* dest net */
u_short srcNet; /* src net */
u_char dstNode; /* dest node */
u_char srcNode; /* src node */
u_char dstSkt; /* dest socket */
...
} ddp;
The variable `ar' is a pointer to the `aroute' struct for the DDP
destination net in the AppleTalk routing table.
4.7.1. IP destination address algorithms
The following are the algorithms for calculating the IP destination
host address of the UDP/DDP datagram expressed in ``C''.
The variable `ip' is of type `struct ip' and describes the IP header
of the outgoing IP datagram;
struct ip {
...
iaddr_t ip_src; /* IP source address */
iaddr_t ip_dst; /* IP dest address */
} ip;
4.7.1.1. Algorithm A
Algorithm A is used to deliver unicast (non-broadcast) packets on
``Host'' and ``Net'' networks directly to the destination host on a
UDP/DDP network. The IP destination is formed by taking the high 24
bits from `node', and the low 8 bits from the DDP destination node
number.
ip.ip_dst = (ar->node & ~0xff) | ddp.dstNode;
Budne Expires December 31, 1993 [Page 9]
DRAFT KIP AppleTalk/IP Gateway July 1993
4.7.1.2. Algorithm B
Algorithm B is used to broadcast packets to ``Net'' networks, relying
on directed broadcast delivery. The IP destination is formed using
the `node' field and as many low order octets of ones as specified by
the `arouteBMask' field of `flags'. If the destination AppleTalk
network is the connected Ethernet UDP/DDP network, the configured IP
broadcast address (member `ipbroad' in the configuration structure)
is used as the IP destination.
u_long ipbroadtypes[] = { 0, 0xff, 0xffff, 0xffffff };
/* directly connected UDP/DDP net? */
if( ddp.destNet == ifie.if_dnet ) {
/* use configured IP broadcast */
ip.ip_dst = conf.ipbroad;
}
else {
/* create directed broadcast */
ip.ip_dst = ar->node |
ipbroadtypes[ ar->flags & arouteBMask ];
}
4.2 BSD style (zero-fill) broadcast addresses (for networks with 8
bits of host) can be generated by specifying zero octets of ones.
Networks that cannot be reached with broadcast addresses that do not
have a integral number of low-order one-filled octets cannot use
``Net'' routes, and must use ``Host'' routes (see below).
4.7.1.3. Algorithm C
Algorithm C is used for delivery of broadcasts on ``Host'' networks,
and all packets on ``Kbox'' and ``Async'' networks to a specific host
address. The IP destination is the IP host specified in the `node'
(next IR) field .
ip.ip_dst = ar->node;
Budne Expires December 31, 1993 [Page 10]
DRAFT KIP AppleTalk/IP Gateway July 1993
4.7.2. UDP destination port algorithms
The following are the algorithms for calculating the UDP destination
port of the UDP/DDP datagram expressed in ``C'', using the following
structure for the output UDP header;
struct udp {
u_short uh_src; /* source port */
u_short uh_dst; /* destination port */
...
} udp;
4.7.2.1. Algorithm P
Algorithm P is used for delivery of all packets on ``Net'' and
``Kbox'' networks and unicast packets on ``Host'' networks. Packets
for each possible DDP socket are directed to a different UDP port on
the destination host.
``Static'' or ``Well Known'' DDP sockets (those below 128) originally
used a UDP port base of 768 (300 hex), however in April of 1988 the
NIC reserved ports 201 through 208 (a port base of 200) for use by
KIP [RFC-1060]. UDP ports 768 and 200 are never used, since use of
DDP socket zero is illegal. See the ``Discussion'' section below.
The UDP port range used for static DDP sockets is configured via the
`aaCONF' packet (ie; from `atalkatab'). The UDP port range base used
for ``dynamic'' DDP sockets is fixed at 16384 (4000 hex).
Budne Expires December 31, 1993 [Page 11]
DRAFT KIP AppleTalk/IP Gateway July 1993
#define ddpWKSBase 200 /* start of NIC WKS range */
#define oddpWKSBase 768 /* start of old WKS range */
#define ddpNWKSBase 16384 /* non WKS... */
/* "well known" (ie; static) socket number?? */
if( ddp.dstSkt < 128 ) {
if( conf.startddpWKS == 0 ) {
/* no WKS range configured
* be backwards compatible
*/
startddpWKS = oddpWKSBase;
}
else {
/* usually ddpWKSBase (200) */
startddpWKS = conf.startddpWKS;
}
udp.uh_dport = ddp.dstSkt + startddpWKS;
}
else /* not a WKS, use NWKS port range */
udp.uh_dport = ddp.dstSkt + ddpNWKSBase;
4.7.2.2. Algorithm Q
Algorithm Q is used to deliver DDP broadcasts for ``Host'' networks
to a ``rebroadcast'' server for local broadcast or selective directed
delivery.
#define rebPort 902
udp.uh_dport = rebPort;
4.7.2.3. Algorithm R
Algorithm R is used to deliver DDP unicast packets for ``Async''
networks to the async server host based on the DDP destination node.
This is done so that each dialin user running the `async' program can
receive packets destined for their node without additional handling
on the server host.
#define aaBasePort 0xAA00 /* Async AppleTalk base port */
udp.uh_dport = aaBasePort + ddp.dstNode;
Budne Expires December 31, 1993 [Page 12]
DRAFT KIP AppleTalk/IP Gateway July 1993
4.7.2.4. Algorithm S
Algorithm S is used to deliver DDP Broadcasts for ``Async'' networks
to a single UDP port so that the `asyncad' daemon can forward the
packet to all registered `async' dialin users on the Un*x host.
#define aaBroadPort 750 /* aabroad in /etc/services */
udp.uh_dport = aaBroadPort;
4.7.3. Discussion
The primary benefit realized by the DDP/UDP port mapping expressed in
Algorithm P is the efficient implementation of AppleTalk on systems
with a system level UDP implementation and no system level AppleTalk
(ie; Vanilla BSD Un*x), as system level UDP port demultiplexing is
used to deliver the DDP packets directly to the user process.
Creating this one-to-one relationship between DDP sockets and UDP
ports on the UDP/DDP host is feasible because the size of the DDP
socket space is much smaller than the UDP port space (2^8 vs. 2^16).
Furthermore the UDP ports in the WKS and NWKS ranges can be used for
other purposes, but only those ports can be used for UDP/DDP
applications.
However it is difficult to implement a UDP/DDP AppleTalk interface on
a system with both formalized UDP and DDP layers (ie; a UDP/DDP
``adev'' for a Mac using ``MacTCP 1.0''). A similar difficulty is
seen implementing a UDP/DDP AppleTalk router in a user process on a
system with a typical system level UDP implementation (ie; Un*x), as
the router process has to listen on and send from 254 different UDP
ports.
Ed Moy of UCB has done work on a version of IPTalk that uses only one
UDP port for transmissions between hosts.
4.8. KIP UDP/DDP input processing
When KIP receives UDP input on a port in either the ``Well Known'' or
``Not Well Known'' DDP socket range, it strips the UDP and pseudo LAP
headers, and passes the (long) DDP packet to the regular DDP input
layer.
4.9. KIP Route Aging
KIP ages all AppleTalk routes every 20 seconds. Local (RTMP) routes
are kept for two aging periods, while learned IP routes are kept for
Budne Expires December 31, 1993 [Page 13]
DRAFT KIP AppleTalk/IP Gateway July 1993
16 periods. Initial IP routes (from atalkad), and routes for directly
connected networks are never aged.
4.10. CAP routing
Each CAP client keeps the IP address, DDP network and node numbers of
the last host from which it received a UDP/DDP packet. This means
that CAP is able to return some packets without sending them first to
a local gateway (in violation of Phase 1 rules)!! If on output the
DDP destination net and node both match the cached information, the
packet is sent to the cached IP address, otherwise the packet is
routed to a single statically configured local gateway.
4.11. CAP socket assignment
When a CAP client or server wishes to obtain a dynamic DDP socket it
must search the UDP port range associated with the DDP ``Not Well
Known'' socket range for a free local UDP port. Since the UDP ports
in both the old and new ``Well Known'' (static) ranges are below
1024, only processes executing as ``super user'' may open them.
Name Information Table (NIT) maintenance for CAP hosts is implemented
in a single process, by a program named `atis' (the appletalk
information server). `Atis' listens on the Name Information Socket
(NIS) for `LkUp' requests and sends `LkUp-Reply' packets. CAP
servers must send special register and unregister requests to `atis'
to modify the NIT.
`Atis' also listens on DDP socket 4 for AppleTalk Echo Protocol (AEP)
packets, and will send an `echoReply' for each `echoRequest'
received.
4.12. CAP Zones
Each CAP host is staticly configured with a zone name, and `atis'
will only answer NBP `LkUp''s in its own zone. NBP `LkUp''s sent by
KIP always include the zone (never ``*''). See section on the magic
`ALL' zone.
4.13. AppleTalk Administration (AA) packets
KIP is downloaded with a configuration that specifies only it's own
IP address, a default router and the address of an administrator host
which will supply additional configuration information. KIP receives
this configuration information and exchanges routing information on
UDP port 901 (the `aaPort'). The packets used are called AppleTalk
Administration, or ``AA'' packets. KIP will only accept AA packets
Budne Expires December 31, 1993 [Page 14]
DRAFT KIP AppleTalk/IP Gateway July 1993
sent from it's configured AppleTalk Administrator host (member
`ipadmin' in configuration), IP debug host (member `ipdebug' in
configuration), or from any ``Kbox'' marked as from the AA host in
the `aroute' table. Each packet must have a UDP source port of 901.
KIP relies exclusively on the AA protocol to distribute routing
information for UDP/DDP networks; RTMP packets are never exchanged
over UDP/DDP networks. All AA packets have the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: aaMagic (0xFF068030) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: opcode : flags : byte count of stuff :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP address of sender (never checked) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
/ stuff: /
/ config info or route tuples /
/ (up to 512 octets) /
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The data portion of the packet (member `stuff') is limited to 512
octets to avoid IP fragmentation.
Here are the valid `opcode' values;
aaCONF 1 Configuration request/reply
aaROUTEI 2 Initial routes from AA
aaROUTE 3 Route update
aaROUTEQ 4 Route update and query
aaRESTART 5 Force restart
aaZONE 6 Initial zones from AA (obs)
aaZONEQ 7 DDP ZIP over AA
Two recent, commonly implemented extensions (originated by the
University of Melbourne) are:
aaROUTEM 32 More routing info
aaROUTER 33 Request routing info
Budne Expires December 31, 1993 [Page 15]
DRAFT KIP AppleTalk/IP Gateway July 1993
The following are AA protocol extensions which are not widely
implemented (if at all), and will not be discussed further;
A CMU extension:
aaROUTEIS 8 Short initial route table
LBL-KIP extensions (also in K-STAR 9.1);
aaREBOOT 9 Force code download (via BOOTP)
aaRESET 10 Reset code and config
Extensions used by University of Melbourne;
aaPROXY 62 NBP Proxy ARP table
aaPROXYQ 63 NBP Proxy ARP table request
Extensions proposed by Karen Frisa in ``IPTalk routing for AppleTalk
Phase 2'' (7/27/90), but never implemented;
aaROUTERANGE 9 Table update with ranges
aaROUTERANGEQ 10 Table update and query with ranges
Budne Expires December 31, 1993 [Page 16]
DRAFT KIP AppleTalk/IP Gateway July 1993
4.13.1. `aaCONF' packet
On startup KIP sends a minimum length (12 byte) `aaCONF' packet to
the ``AA'' host as a configuration request. The AA host then replies
with a full configuration `conf' structure in the data portion of an
`aaCONF' packet;
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP broadcast address * :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP name server ** :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP debug host :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP file server ** :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ipother[0] ** :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ipother[1] ** :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ipother[2] ** :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ipother[3] ** :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: EtherTalk net : start ddp WKS UDP port range :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: flags :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: # of static clients : # of dynamic clients :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: LocalTalk net : UDP/DDP net :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: spare :
: (was once zone info) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note:
Entries with * are used by KIP and passed to DDP/IP
clients via ``IPGP''. Entries with ** are NOT used by
KIP and are passed to DDP/IP clients via ``IPGP''.
Budne Expires December 31, 1993 [Page 17]
DRAFT KIP AppleTalk/IP Gateway July 1993
Values for `flags' (may be OR'ed together);
Flag Value Meaning
conf_stayinzone 1 No looking at other zones
conf_laserfilter 2 NBP LaserWriter filtering
conf_tildefilter 4 NBP Tilde filtering
4.13.2. Routing Tuples
`aaROUTEI', `aaROUTE', `aaROUTEQ', and `aaROUTEM' packets contain
routing tuples (called `arouteTuple''s) of the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP net or host :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: atalk net : flags : hops :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The `flags' field of the `arouteTuple' uses the same flags as the
`aroute' structure.
NOTE: This differs from RTMP in that it contains the explicit address
of the ultimate destination.
4.13.3. `aaROUTEI' packet
The AA host sends KIP an `aaROUTEI' packet to install an initial
(static) routing table. On receipt of an `aaROUTEI', KIP flushes all
routes marked as ``from AA'' (with the `arouteAA' flag set), and
inserts the enclosed routes into it's routing table marked as ``from
AA''.
The `atalkad route' command sends KIP an unsolicited `aaROUTEI'
packet.
On startup KIP sends a minimum length (12 byte) `aaROUTEI' packet as
a request every 60 seconds until a reply is received.
4.13.4. `aaROUTEQ' packet
Once a minute KIP sends an `aaROUTEQ' packet to a ``core'' gateway.
Core gateways are those Kboxes which appear in KIP's routing table as
``Kbox'' routes with the `arouteCore' flag set. The core gateways
are sent to in turn, round-robin. ``Core'' gateways send `aaROUTEQ'
Budne Expires December 31, 1993 [Page 18]
DRAFT KIP AppleTalk/IP Gateway July 1993
as well (KIP does not contain code to detect whether it is a ``core''
gateway or not), but a ``core'' gateway will skip it's own address.
The `aaROUTEQ' packet contains ``Kbox'' routes (with the gateway IP
address in the `node' field) for each AppleTalk route that the
gateway has learned via RTMP (those which qualify as ``Local''
routes).
On receipt of an `aaROUTEQ' KIP merges the routes into it's routing
table and replies with an `aaROUTE' packet containing ALL routes
which are not marked as ``from AA''.
4.13.5. `aaROUTE' packet
On receipt of an `aaROUTE' packet KIP merges the contained routes
into it's routing table.
4.13.6. `aaRESTART' packet
KIP will restart execution upon receipt of an `aaRESTART' packet.
The `atalkad boot' command sends an `aaRESTART' packet to each Kbox
in `/etc/atalkatab'.
4.13.7. `aaZONE' packet
`aaZONE' is an obsolete packet format used for zone information. KIP
06/88 does not send or process `aaZONE' packets. An empty `aaZONE'
packet was sent by KIP as a request, and returned with data by
`atalkad'.
The format of `aaZONE' packet data is a list of (2 byte) AppleTalk
network numbers terminated by a zero net number and followed by a
``pascal'' string (ie; string prefixed by a byte count byte) for the
zone. The packet is terminated by an network number of all ones (hex
`0xffff').
4.13.8. `aaZONEQ' packet
`aaZONEQ' packets contain regular DDP ZIP `Query' and `Reply'
packets.
KIP sends `aaZONEQ' packets containing ZIP `Query' requests to the AA
host for routes marked as ``from AA'' or to the IP address in the
`node' field of the route for routes learned via ``core'' gateways.
KIP and atalkad respond to `aaZONEQ' encapsulated Queries with ZIP
`Reply' packets inside a `aaZONEQ'.
Budne Expires December 31, 1993 [Page 19]
DRAFT KIP AppleTalk/IP Gateway July 1993
4.13.9. `aaROUTER' packet
This is a recent extension implemented in Rutgers KIP (RU-KIP) and
various commercial offerings. If the `flags' field in the AA packet
header of the `aaROUTEI' packet returned by the AA host is non-zero,
it is interpreted as a count of the total number of initial route
packets. The `flags' field of the AA packet header in an `aaROUTER'
packet is interpreted as an initial route packet ``serial number''.
Since the `aaROUTEI' packet contains the first 64 routes, the first
`aaROUTER' request contains the value one in the `flags' field.
4.13.10. `aaROUTEM' packet
This is a recent extension implemented in Rutgers KIP and various
commercial offerings. `Atalkad' sends the n-th additional initial
route packet in response to the `aaROUTER' request in an `aaROUTEM'
packet. RU-KIP increments its request serial number regardless of
the contents of the `flags' field in the incomming `aaROUTEM' AA
packet header.
4.14. Aroute input Processing
KIP uses the same code to integrate new routes regardless of whether
they were acquired using the AA protocol or RTMP. Of particular note
is that hopcount values are incremented on input, and that worse-cost
changes are only accepted if the new destination node matches the
currenly saved `node' value. Thus the AA protocol is being treated
as a distance vector routing protocol.
However, distance vector routing systems depend on the fact that
routing tuple hopcounts reflect actual distance because the routing
data traverses the same path as the network data. This is not true
for the AA protocol; Data packets are sent directly without
traversing the core gateways through which the routing data was
passed, so the hopcounts of routes obtained from core gateways are
too high.
In the presense of more than one core gateway, the hopcount of a core
gateway learned route will often be inflated owing to the route being
passed between core gateways since the ``destination'' host will be
the same, the longer route will be accepted. With two or more core
gateways, routes can take more than an hour to die.
Because the AppleTalk distance from any one ``Kbox'' to another is
always one hop (the actual number of intervening IP gateways cannot
be detected) the AppleTalk cost should be propogated though the core
gateway routing system unchanged. However then another metric would
be needed limit route lifetime (by couting the number of router
Budne Expires December 31, 1993 [Page 20]
DRAFT KIP AppleTalk/IP Gateway July 1993
traversals to ``infinity'' or by counting route ``time to live'' down
to zero).
4.14.1. Initial routes
The `atalkad' supplied with KIP 06/88 sends a hopcount of zero for
all routes in the `aaROUTEI' packet (all other versions supply a
hopcount of one), so all initial entries in the routing table will be
one hop away (except for the directly connected LocalTalk, EtherTalk
and UDP/DDP networks).
4.15. AppleTalk Administrator Packet Exchanges
The following tables show AA packet exchanges involving KIP.
4.15.1. restart
This occurs when an user issues the `atalkad boot' command.
`Atalkad' sends an `aaRESTART' to each ``Kbox'' in `/etc/atalkatab'.
AA Host KIP
_______________________
aaRESTART
KIP reboots
4.15.2. KIP boot sequence
On startup KIP requests configuration information from the AppleTalk
Administrator (AA) host by sending minimum length `aaROUTEI' packets
once a minute until it gets a response.
AA Host KIP
_____________________________________
aaCONF (no data)
aaCONF (with data)
followed by either the ``atalkad route sequence'' or ``atalkad route
Budne Expires December 31, 1993 [Page 21]
DRAFT KIP AppleTalk/IP Gateway July 1993
sequence with extension''
4.15.3. atalkad route sequence
The ``atalkad route sequence'' occurs as part of the ``KIP boot
sequence'' or as the result of an `atalkad route' command. The
contents of the AA packet header `flags' field is shown in brackets.
AA Host KIP
______________________
aaROUTEI[0]
aaROUTEQ
4.15.4. atalkad route sequence with extension
The ``atalkad route sequence with extension'' occurs as part of the
``KIP boot sequence'' or as the result of an `atalkad route' command
when the gateway implements the `aaROUTER' and `aaROUTEM' packets and
the `flags' sent with the `aaROUTEI' packet were non-zero.
The contents of the AA packet header `flags' field is shown in
brackets.
AA Host KIP
_____________________________
aaROUTEI[n]
aaROUTER[1]
aaROUTEM[1]
aaROUTER[2]
aaROUTEM[2]
...
...
aaROUTER[n-1]
aaROUTEM[n-1]
aaROUTEQ
4.15.5. `aaZONEQ' exchange
KIP sends ZIP `Query' and `Reply' packets encapsulated in `aaZONEQ'
packets to either the AA host, or other Kboxes to acquire the zone
name for networks reached via UDP/DDP encapsulation.
KIP AA Host or KIP
_______________________________________
aaZONEQ(ZIP Query)
Budne Expires December 31, 1993 [Page 22]
DRAFT KIP AppleTalk/IP Gateway July 1993
aaZONEQ(ZIP Reply)
4.15.6. Core GW exchange
KIP sends RTMP learned ``Local'' routes to Kboxes marked as ``core''
gateways in it's routing table. The core gateway responds with all
UDP/DDP routes not marked as ``from AA''.
KIP KIP Core GW
______________________
aaROUTEQ
aaROUTE
4.16. Rebroadcast Port
KIP accepts UDP packets on port 902 (the `rebPort') if the
destination IP address matches the gateway address (broadcasts are
not accepted, nor are packets rerouted), and passed to the ddpinput
routine for processing based on the embedded DDP destination.
If the packet is a DDP broadcast, KIP will broadcast the packet using
the configured broadcast address as the IP destination, while the
Un*x `atalkrd' server distributed with KIP can be given a list of
addresses (via command line arguments) for forwarding packets.
4.17. `atalkatab'
The Un*x AA server implementation distributed with KIP is called
`atalkad', and the configuration file read by atalkad is called
`atalkatab'.
atalkatab format is best compared to assembly language; each line is
a textual representation of binary structures to be generated and
stored for later retrieval.
4.17.1. route line format
Initial routes and zones to be sent in `aaROUTEI', `aaROUTEM' and
`aaZONEQ' replies are generated by ``route lines'' of the following
format;
net flags ipaddr zone
Where net is the DDP net to be configured. As mentioned earlier,
nets may be represented as a pair of dotted decimal octets, or as a
Budne Expires December 31, 1993 [Page 23]
DRAFT KIP AppleTalk/IP Gateway July 1993
simple decimal integer.
flags is a series of mnemeonic characters which represent values to
``OR'' together to generate the `arouteTuple' flags field;
character(s) bit(s)
_____________________________________
0123 arouteBmask
A arouteHost+arouteAsync
C arouteCore
E arouteKbox+arouteEtalk
K arouteKbox
H arouteHost
N arouteNet
The digits zero through three the corresponding binary value to be
``ORed'' into the flags field (to set the ``Net'' broadcast format).
ipaddr is an IP address to be stored in the `node' field.
4.17.2. Kbox configuration section
Configuration for ``Kboxes'' to be sent in `aaCONF' packets is
represented on whitespace prefixed lines following a K line.
Configuration information is a series of key-characters which control
both the interpretation of the data to follow, and the amount of data
to be stored.
key interpretation size in bytes
_____________________________________________
I Internet host name/addr 4
L Long integer 4
S Short integer 2
%n net config 2
B Byte integer 1
Integer data is interpreted as decimal unless prefixed with the
letter `X', numbers prefixed with a leading zero are interpreted as
octal. Short integers can be entered as dotted pairs.
The pair of characters `%n' has magic properties when it appears at
the data offsets associated with the configuration for each of the
AppleTalk ``ports''; LocalTalk, EtherTalk, and UDP/DDP.
For the LocalTalk port `%n' takes on the value of the net number on
the preceding `K' line. For the EtherTalk port `%n' takes on the
Budne Expires December 31, 1993 [Page 24]
DRAFT KIP AppleTalk/IP Gateway July 1993
value of the net number on the first preceding `E' line where the
ipaddr of the `E' line matches the IP address of the current Kbox.
For the UDP/DDP port `%n' takes on the value of the net number on the
first `H' or `N' line where the top three bytes of the ipaddr of the
`H' or `N' line matches the IP address of the current Kbox.
In addition strings of characters may be entered delimited with
``quote'' character (ASCII 34). Counted ``PASCAL'' strings may be
entered delimited with the ``accent grave'' or ``backquote''
character (ASCII 96).
4.18. Related DDP in IP encapsulations
KIP-style DDP in IP encapsulation has been used in two other
contexts. Both use the same pseudo-LAP header as KIP UDP/DDP, but
use different UDP ports.
4.18.1. UAB ``mKIP'' encapsulation
UAB (Un*x AppleTalk Bridge) is a Phase 1 AppleTalk Router which runs
on Un*x systems and speaks EtherTalk Phase 1. UAB communicates with
CAP client software on the local host (via UDP to the loopback
address) using an encapsulation called ``modified KIP''. Because it
would be impossible to configure CAP with the local host as the
``bridge node'' (both because this would require opening more than
200 Un*x ``sockets'', and because doing so would prevent the clients
from opening any), UAB listens on the UDP port 903 (the `mrebPort'),
for packets from local clients to be routed to EtherTalk.
4.18.2. Point to Point links using RTMP
Cayman and other vendors use KIP style DDP/IP encapsulation on UDP
port 910 to implement point to point ``tunnels'' between gateways.
Phase 2 RTMP and ZIP are sent (to and from DDP net and node zero)
across the ``link'' (as determined by IP source) to exchange routing
and zone information.
Owing to the high update rate of RTMP, it is impractical to create
large fully connected routing systems due to the quadratic number of
links (n^2 - n) and update packets.
5. NBP Filtering
KIP performs three types of NBP based filtering; ``Stay in Zone'',
Budne Expires December 31, 1993 [Page 25]
DRAFT KIP AppleTalk/IP Gateway July 1993
``LaserWriter'', and ``Tilde''.
Note:
5.1. Stay in Zone filtering
``Stay in Zone'' filtering (enabled by the `conf_stayinzone' flag) is
the most restrictive type. If enabled, machines on the gateway
LocalTalk will only be able to access resources within their own zone
through KIP. Access to ANY resource outside this zone will be
prevented.
``Stay in Zone'' filtering is implemented by never sending NBP `LkUp'
requests (when expanding NBP `BrRq' requests) to nets which are not
in the same zone as the LocalTalk port, and by sending empty replies
for ZIP `GetZoneList' requests, so that no zone list appears in the
Macintosh ``chooser''.
5.2. LaserWriter filtering
``LaserWriter filtering'' (enabled by the `conf_laserfilter' flag)
allows free access to LaserWriters in the gateway's LocalTalk zone by
all members of this zone. However machines outside this zone will be
unable to see any LaserWriters behind this Kbox.
``LaserWriter filtering'' is implemented by routing NBP `LkUp-Reply'
packets which contain NBP type `LaserWriter' ONLY if the source net
is in the same zone as the gateway's LocalTalk or the source and
destination nets are both in the gateway's LocalTalk zone.
Note:
Absolute determination of the source and destination
zones from net numbers are only possible in an AppleTalk
Phase 1 environment!
5.3. Tilde filtering
``Tilde filtering'' (enabled by the `conf_tildefilter' flag) is
similar to ``LaserWriter Filtering''. By default, all NBP names will
be accessible outside the gateway LocalTalk zone. However if an NBP
entity name ends in the tilde character ``~'' (e.g. `Our Printer~'),
then this name will no be seen by machines outside of the zone.
Note:
When KIP performs `LaserWriter' and ``Tilde'' filtering
it only looks at the first tuple of the NBP `LkUp-Reply'
Budne Expires December 31, 1993 [Page 26]
DRAFT KIP AppleTalk/IP Gateway July 1993
packet. If the first tuple matches the filtering test,
the entire packet will be dropped. If the first tuple
fails the filtering test the entire packet will be
dropped.
6. Magic `ALL' zone
The zone name `ALL' has magic properties to KIP; it allows CAP hosts
on an Ethernet with one gateway to appear in disparate zones. NBP
`LkUp''s are always sent to nets in zone `ALL', regardless of the
target zone in the `BrRq' packets. KIP will never return the zone
name `ALL' in a ZIP `GetZoneList' reply, so it will never be seen in
a list of zones (ie; Mac ``Chooser'' or CAP `getzones'). Since KIP
always replaces ``*'' with the source zone of the `BrRq' and `atis'
checks the zone on incoming `LkUp''s each CAP host will only appear
in one zone.
7. Gateway Debug protocol
KIP provides for remote examine and deposit of memory locations by
the configured `ipdebug' host via packets sent to UDP port 900 (the
`gwdbPort').
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: gwdbMagic (0xFF068020) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: op : seq : count :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
/ data /
/ (up to 512 octets) /
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`op' codes for gwdb;
gwdbRead 1 Read memory
gwdbWrite 2 Write memory
gwdbCall 3 Not implemented
Budne Expires December 31, 1993 [Page 27]
DRAFT KIP AppleTalk/IP Gateway July 1993
LBL KIP uses the following op codes:
gwdbStats 4 Return statistics
gwdbState 5 Return configuration
gwdbFrame 6 Return stack frame
Shiva uses the following op code for remote debug with GDB:
gwdbGdb 99
7.1. gwdb Read function
`count' octets starting at `address' in the gateway memory are copied
to `data', and the packet is returned.
7.2. gwdb Write function
`count' octets of data from `data' are copied to `address' in the
gateway memory and the packet is returned unmodified.
7.3. gwdb Call function
KIP does not implement this function! For unimplemented functions
KIP clears the `op' byte and returns the packet.
7.4. gwdb State function
This function is implemented by LBL KIP and K-STAR, and returns
FastPath specific information in `data';
/*
* Structure of data area in a 'state' reply.
*/
struct gwdb_State {
struct fp_version version;
struct fp_state state;
};
7.5. gwdb Stats function
This function is implemented only by LBL KIP.
Budne Expires December 31, 1993 [Page 28]
DRAFT KIP AppleTalk/IP Gateway July 1993
7.6. gwdb Frame function
This function is implemented by LBL KIP and K-STAR and returns the
machine state of the processor; D0-D7, A0-A7, SR (left padded to 32
bits).
7.7. gwdb Gdb function
Shiva uses this function. The following remote gdb commands are
supported:
Command Function Return value
___________________________________________________________________
g return the value of the CPU registers ENN / data
G set the value of the CPU registers ENN / OK
mAA..AA,LLLL Read LLLL octets at address AA..AA ENN / data
MAA..AA,LLLL Write LLLL octets at address AA..AA ENN / OK
c[AA..AA] Continue [at address AA..AA] SNN
s[AA..AA] Step one instruction [from AA..AA] SNN
? What was the last signal? SNN
k kill (ignored)
Where ``AA..AA'', ``LLLL'' and ``NN'' are in hex. ``SNN'' represents
an exception encoded as a Un*x `signal' number NN and ``ENN''
represents an error condition. All returns marked ``data'' are
streams of octets encoded in hexadecimal.
8. DDP/IP encapsulation
Note:
While the Apple-IP Working Group of the IETF is working to
standardize and extend the protocols for IP over AppleTalk,
however no description exists of the historical
implementation.
KIP provides an IP ``forwarding'' capability that allows AppleTalk
nodes appear to be located on the Ethernet by sending ``proxy ARP''
replies for IP addresses in a ``client range''.
The DDP/IP encapsulation protocol consists of three parts;
Encapsulation, Dynamic address assignment, and Address Resolution.
8.1. Encapsulation
IP Datagrams are encapsulated in DDP packets of type 22 with DDP
source and destination sockets of 72.
Budne Expires December 31, 1993 [Page 29]
DRAFT KIP AppleTalk/IP Gateway July 1993
8.2. Address Resolution
KIP uses AppleTalk NBP `LkUp''s to achieve IP address resolution.
This allows routing of IP packets within an AppleTalk zone, without
requiring any changes to intermediate DDP routers within the zone.
Each DDP/IP host must NBP register a tuple of type `IPADDRESS' with
the object name set to the dotted decimal representation of the
host's IP address. This ensures that only one host is using an IP
address at a time, and allows hosts (both Macintoshes and KIP) to
locate each other by address using NBP.
KIP maintains DDP addresses alongside Ethernet addresses in it's ARP
cache. When KIP needs to route an IP packet to a client (static or
dynamic) which does not appear in the cache, it performs an NBP
lookup (as `a.b.c.d:IPADDRESS') in the zone associated with the Kbox
LocalTalk port. Because of this clients must be located in the same
zone as the Kbox.
NBP replies for type `IPADDRESS' are always processed as both ARP
replies and dynamic address confirmations.
8.2.1. NBP Proxy ARP
In order to maintain the illusion that the DDP/IP hosts are located
on Ethernet, KIP must reply in proxy for NBP ARP's for addresses NOT
in the gateway client range (as opposed to on Ethernet where KIP
replies for addresses in the client range) as well as it's own IP
address so that packets for hosts that are really on the Ethernet are
routed via the gateway!
KIP does not reply to NBP ARP's in it's client range to allow clients
to NBP register (which requires first performing a zone wide search
for current users of a name). This would prevent more than one
gateway from operating in the same zone (since one gateway or the
other will reply to any IPADDRESS lookup) however, KIP will only send
replies for lookups of type IPADDRESS if the reply would be routed
via the LocalTalk port.
Some DDP/IP client software attempts to resolve all IP addresses into
a DDP destination using NBP ARP (depending on NBP Proxy ARP Replies
from the gateway), while others will only NBP ARP for addresses which
are on the connected IP network (as determined by it's own IP address
and a (sub)net mask), and route all other packets via a default
gateway on the connected net.
Budne Expires December 31, 1993 [Page 30]
DRAFT KIP AppleTalk/IP Gateway July 1993
8.2.2. DDP ARP
Another method was previously used for DDP/IP IP Address Resolution.
Work done in the summer of 1984 at Dartmouth [Sherman86] treated the
LocalTalk as a distinct IP network, and sent ARP [RFC-826] using DDP
type 23, and hardware type 3 for ``AppleBus''.
This method requires that an entire IP (sub)net be assigned for use
by LocalTalk hosts, and at the same time limits the IP (sub)net to a
single LocalTalk wire. IP addresses on the LocalTalk (sub)net can
either be assigned staticly, or the host's LAP node number can be
used as the IP address host part to provide a dynamic IP address!
The original SEAGate code converted between IP and DDP addresses by
equating the DDP net number and IP subnet numbers.
8.3. Dynamic Address Assignment
So that each potential client need not be configured with an IP
address (and that a large number of clients can share a small pool of
addresses), KIP can perform IP address assignment on an on-demand
basis from a pool of ``dynamic'' addresses.
KIP receives configuration for the number of static and dynamic
clients from atalkatab. Up to 60 dynamic addresses can be
configured. Static client addresses follow directly after the
gateway address, and dynamic addresses follow after the static
addresses.
So that potential dynamic clients can locate the gateway, KIP
responds to NBP `LkUp''s of type `IPGATEWAY' with the dotted decimal
representation of it's address as the object name, and socket number
72. KIP will only respond to lookups of type `IPGATEWAY' if it would
route the reply via it's LocalTalk port. This keeps different Mac's
in the same zone, but behind a different gateway on the same Ethernet
from getting an address from the wrong box!
For each dynamic address, KIP keeps the following three-tuple: `net',
`node', `timer'. Where `net' and `node', is the client's DDP
address, and `timer' counts how many minutes have passed since the
entry has been successfully ``confirmed''. A non-zero `timer' value
Budne Expires December 31, 1993 [Page 31]
DRAFT KIP AppleTalk/IP Gateway July 1993
indicates the entry is in use.
8.3.1. IPGATEWAY Protocol
The protocol used for dynamic address assignment is called IPGP (for
the IPGATEWAY Protocol), and is sent using ATP. KIP processes IPGP
packets received on DDP socket 72 (KIP accepts and replies to both XO
and ALO ATP requests, but provides only ALO service).
8.3.1.1. ipgp packet format
The four ATP ``user bytes'' (in the ATP header) are ignored.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: op :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP name server :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP broadcast address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IP file server :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ipother[0] :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ipother[1] :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ipother[2] :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ipother[3] :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
/ /
/ string (128 octets) /
/ /
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.3.1.2. functions
ipgpAssign 1 Assign new IP address
ipgpName 2 Name lookup
ipgpServer 3 Return just server addresses
Budne Expires December 31, 1993 [Page 32]
DRAFT KIP AppleTalk/IP Gateway July 1993
ipgpRange 4 Return start address and range
ipgpVerify 5 Verify this IP address is mine
Only `ipgpAssign' and `ipgpServer' have ever been implemented by KIP.
If an error occurs processing an IPGP packet, KIP sets `op' to -1
(all ones), and returns a zero terminated error message in the
`string' field. The string `bad op' is returned if the `op' field is
not either `ipgpAssign' or `ipgpServer'.
8.3.1.3. ipgp Assign function
The `ipgpAssign' function attempts to allocate an available dynamic
IP address using the following criteria (in descending preference);
(1)
The lowest IP address for which the saved DDP address associated with
the dynamic IP address matches the DDP source address of the
`ipgpAssign' packet.
(2)
The highest IP address entry that has never been used (ie; `timer' is
zero).
(3)
The oldest entry which is more than five minutes old.
(4)
If no entry has been idle (failed address confirmation) more than
five times, then address assignment fails, and the packet is returned
with `op' set to -1 and `string' is set to `no free address'.
If an address is successfully (re)assigned it will be returned in the
`ipaddress' field of the IPGP packet, the client DDP address is saved
in the dynamic client table, and the entry timer is set to one. The
IPGP `op' field is returned unmodified. The `ipname', `ipbroad',
`ipfile' and `ipother' fields are filled in with data received from
the AA host via an `aaROUTEI' packet.
8.3.1.4. ipgp Server function
The `ipgpServer' function returns the auxiliary data fields returned
by `ipgpAssign' but without assigning an address. This function can
be used by ``static'' clients.
Budne Expires December 31, 1993 [Page 33]
DRAFT KIP AppleTalk/IP Gateway July 1993
8.3.2. reboot and address confirmation
KIP sends NBP `LkUp' packets to locate and confirm users of dynamic
IP address slots.
To provide robustness in case of gateway failure KIP will attempt to
(re)acquire the address associations in use before the gateway
restarted. After configuration is complete KIP waits 25 seconds (to
allow RTMP routes to be established) and it sends out wildcard NBP
`LkUp' packets for type `IPADDRESS' in the zone associated with it's
LocalTalk once a second for five seconds. Incoming NBP packets with
type `IPADDRESS' are passed (as usual) to both NBP ARP input
processing and Dynamic IP Address confirm processing. This reloads
the Dynamic IP Address table with all active users (within the local
zone).
Once KIP has been running for 30 seconds, KIP attempts to ``confirm''
the NBP `IPADDRESS' associated with each dynamic IP address ``slot''
once a minute. Since a maximum of 60 dynamic addresses may be
allocated by KIP, each entry is confirmed on the same ``tick'' of the
second hand, spreading the NBP traffic out. If the aging timer
associated with an entry is zero (an unused entry) or has reached
32767 no confirm is sent.
The confirm packet is an NBP `LkUp' packet (with type object `=' and
zone `*') sent directly to the to the DDP address found in the
dynamic IP address table.
Upon receipt of an NBP reply for an IPADDRESS in the dynamic range
the address confirmation code saves the replying entity's DDP address
in the dynamic client table, and resets the entry timer to one.
9. KIP revision history
Below is an edited revision history for KIP.
9.1. 10/86
Improved IP address management (IPGP + NBP ARP). Centralized
configuration and boot control. Full AppleTalk routing using
NBP/RTMP/ZIP; ``core'' gateway scheme. Gateway debugging via net
ddt. Simple integration with libraries such as CAP/K-HOST. Improved
packet throughput. (Croft)
9.2. 02/87
Bug fixes. (Croft)
Budne Expires December 31, 1993 [Page 34]
DRAFT KIP AppleTalk/IP Gateway July 1993
9.3. 09/87
Implement zones `(aaZONE)' and zone filtering. (Croft and Kim)
9.4. 01/88
Ethertalk support. Magic zone name `ALL'. ATP ZIP support
rewritten. DDP Echo support. atalkad configuration aids. (Kim and
Tappan)
9.5. 06/88
Support for NIC UDP port range. Zone acquisitions are done on RTMP
routes. EtherTalk fixes. Allzones was on for ``unknown'' zones.
(Kim)
10. NIC Assigned UDP ports
The following UDP ports were assigned for UDP/DDP encapsulation in
April of 1988 [RFC-1060].
Port NIC Name Use
_______________________________________________
201 AT-RMTP AppleTalk Routing Maintenance
202 AT-NBP AppleTalk Name Binding
203 AT-3 AppleTalk Unused
204 AT-ECHO AppleTalk Echo
205 AT-5 AppleTalk Unused
206 AT-ZIS AppleTalk Zone Information
207 AT-7 AppleTalk Unused
208 AT-8 AppleTalk Unused
In regular operation RTMP and ZIP are never sent in UDP/DDP packets.
The CAP `getzones' command sends ZIP `GetZoneList' packets to KIP,
but KIP always sends ZIP `Query' commands in `aaZONEQ' packets to
it's AA host and other Kboxes. The NBP and ECHO are ports are served
by `atis' on CAP hosts.
11. Non-NIC Assigned UDP ports:
The following ports are used by KIP, CAP or work-alikes, but have not
been assigned by the Internet Assigned Numbers Authority;
Port(s) Name Use
___________________________________________________________
750 aaBroadPort Async Appletalk broadcast
Budne Expires December 31, 1993 [Page 35]
DRAFT KIP AppleTalk/IP Gateway July 1993
768-895 ddpWKSUnix Old DDP Well-Known socket range
899 FastPath KLAP3 over UDP
900 gwdbPort Gateway Debug Protocol
901 aaPort AA Protocol
902 rebPort UDP/DDP Rebroadcast
903 mrebPort UAB mKIP Rebroadcast
910 RTMP Point-to-Point
16512-16639 ddpNWKSUnix Non-Well-Known DDP Socket range
43520 aaBasePort Async Appletalk base port
12. Programmer's Reference:
The following are the ``C'' data structure declarations used by KIP
for packets described in this memo;
Note:
All data is in ``network'' (native 68000) byte order.
AppleTalk administration packets from AppleTalk administrator host
(AA) or other gateways; configuration / routing information packet.
struct aaconf {
u_long magic; /* magic number aaMagic */
u_char type; /* op code */
u_char flags;
u_short count; /* byte count of 'stuff' */
iaddr_t ipaddr /* IP address of sender */
u_char stuff[512]; /* config info or route tuples */
};
#define aaconfMinSize 12
#define aaPort 901 /* udp port number */
#define aaMagic ((u_long)0xFF068030)
Routing tuple contained in all `aaROUTE*' packets;
struct arouteTuple {
long node; /* IP net or host address */
u_short net; /* atalk net number */
u_char flags; /* flags, see aroute */
u_char hops; /* hop count */
};
Budne Expires December 31, 1993 [Page 36]
DRAFT KIP AppleTalk/IP Gateway July 1993
Configuration information from `aaCONF' packet;
struct conf {
iaddr_t ipbroad; /* IP broadcast addr */
iaddr_t ipname; /* address of name server */
iaddr_t ipdebug; /* address of debug host */
iaddr_t ipfile; /* address of file server */
u_long ipother[4]; /* other addresses for IPGP */
u_short anetet; /* EtherTalk AT net # */
u_short startddpWKS; /* UDP WKS range start */
u_long flags; /* various bit flags */
#define conf_stayinzone 0x1 /* no looking at other zones */
#define conf_laserfilter 0x2 /* NBP filter LaserWriters */
#define conf_tildefilter 0x4 /* NBP filter "name~" */
u_short ipstatic; /* static IP addrs */
u_short ipdynamic; /* dynamic IP addrs */
u_short atneta; /* LocalTalk AT net # */
u_short atnete; /* UDP/DDP AT net # */
u_char spare[16]; /* was once zone info */
};
Gateway debug protocol (via ddt68 on Un*x);
struct gwdb {
u_long magic; /* magic number gwdbMagic */
u_char op,seq; /* op code, sequence number */
u_short count; /* byte count */
u_long address; /* address of read/write */
u_char data[512];
};
#define gwdbMagic ((u_long)0xFF068020)
#define gwdbPort 900 /* udp port number */
/* op codes */
#define gwdbRead 1
#define gwdbWrite 2
#define gwdbCall 3
Budne Expires December 31, 1993 [Page 37]
DRAFT KIP AppleTalk/IP Gateway July 1993
IPGATEWAY protocol ATP packet used by client MacIP programs to
request name assignment and lookup services.
struct IPGP {
u_long op; /* opcode */
long ipaddress; /* my IP address (or lookup reply)*/
long ipname; /* address of my name server */
long ipbroad; /* my broadcast address */
long ipfile; /* my file server */
long ipother[4]; /* other addresses/flags */
char string[128]; /* null terminated error string */
};
#define ipgpMinSize 36
/* op codes */
#define ipgpAssign 1 /* assign new IP address */
#define ipgpName 2 /* name lookup */
#define ipgpServer 3 /* just return my server addresses */
#define ipgpRange 4 /* return start address and range */
#define ipgpVerify 5 /* verify this IP address is mine */
#define ipgpError -1 /* error return; string=message */
13. Author's Note:
Portions of this document were copied from KIP source files covered
by the following copyrights:
(C) 1984, Stanford Univ. SUMEX project.
May be used but not sold without permission.
(C) 1986, Kinetics, Inc.
May be used but not sold without permission.
(C) 1986, Stanford, BBN, Kinetics.
May be used but not sold without permission.
(C) 1986, Stanford Univ. CSLI.
May be used but not sold without permission.
(C) 1986, Stanford Univ. SUMEX project.
May be used but not sold without permission.
Budne Expires December 31, 1993 [Page 38]
DRAFT KIP AppleTalk/IP Gateway July 1993
The following are trademarks;
AppleTalk, EtherTalk, LaserWriter, and LocalTalk are
trademarks of Apple Computer, Inc.
FastPath is a registered trademark of Novell
licensed for use exclusively by Shiva Corporation.
K-STAR is a trademark of Novell
licensed for use exclusively by Shiva Corporation.
Kinetics is a registered trademark of Novell.
Mac and Macintosh are registered trademarks of
Apple Computer, Inc.
Un*x is not a trademark of anyone.
14. References:
[RFC-768]
Postel, J.B., ``User Datagram Protocol'', Information Sciences
Institute, University of Southern California, August 1980.
[RFC-791]
Postel, J.B., ``Internet Protocol'', Information Sciences Institute,
University of Southern California, September 1981.
[RFC-826]
Plummer, D.C. ``Ethernet Address Resolution Protocol'', November
1982.
[RFC-1060]
Reynolds, J., and J. Postel, ``Assigned Numbers'', Information
Sciences Institute, University of Southern California, March 1990.
[Sherman86]
Sherman, M. ``A Network Package for the Macintosh using the DoD
Internet Protocols'', Technical Report PCS-TR86-124, Computer Network
Laboratory, Department of Mathematics and Computer Science, Dartmouth
College.
[Sidhu90]
Sidhu, G., R. Andrews and A. Oppenheimer, ``Inside AppleTalk, Second
Budne Expires December 31, 1993 [Page 39]
DRAFT KIP AppleTalk/IP Gateway July 1993
Edition'', Apple Computer, Inc. May 1990.
15. Acknowledgments:
The author is indebted to the following for their help, input and
documentation; Scot Drysdale of Dartmouth University, Robert Elz of
the University of Melbourne, Tom Evans of Webster Computer, David
Hornsby of the University of Melbourne, Charlie Kim of Apple
(formerly at Columbia University), Philip Koch of Dartmouth
University (now at Apple Computer), Stephen Lewis (formerly of
Kinetics), Josh Littlefield of Cayman, John Norstad of North Western
University, Brad Parker of Cayman, Mark Sherman of Transarc (formerly
at Dartmouth), Michael Swan of Neon Software (formerly of Kinetics),
Dan Tappan (formerly at BB&N), and Jim Warner of UCSD.
And particularly Bill Croft (now at the Institute for Global
Communication) not only for having created SEAGate and KIP, but for
his time spent digging up old documentation, and reviewing this
document!
16. Author's Address:
Philip Budne
Shiva Corporation
1 Cambridge Center
Cambridge, MA 02142
Phone: 617-252-6300
EMail: phil@Shiva.COM
17. Expiration:
This draft document expires December 31, 1993.
Budne Expires December 31, 1993 [Page 40]
